前言

之前的文章介紹了如何利用 ReplicaSet 或 Replication Controller 來建立多個 Pod，但這些都是寫死的設定，沒辦法根據當前狀況而有變動，通常一個應用程式會有所謂的尖峰期以及離峰期，假如我們都是用這種死板板的方式來建立多個 Pod，那豈不就要根據時間重新設定 Replica 嗎？這樣真的太累了所以今天筆者要來介紹如何利用 K8s 自身的功能來達到自動生成 Pod 的效果。

Scaling

首先要來介紹一個專業術語：Scaling，Scaling 代表的是縮放的意思，一般來說 Scaling 有分水平縮放(Horizontal Scaling)以及垂直縮放(Vertical Scaling)，接下來就講講這兩種縮放的差別吧！

• Horizontal Scaling

  Horizontal Scaling 通常都是為了增加連接端點，以達到分散流量的作用，讓每個伺服器的負擔不會過大，像之前所介紹利用 ReplicaSet 或 Replication Controller 產生的多個 Pod 都是屬於 Horizontal Scaling。

• Vertical Scaling

  Vertical Scaling 通常是為了讓旗下的伺服器能擁有更多的資源存取量，有種上對下的感覺，上面的人給越多東西底下的人才能做更多事情，通常 Vertical Scaling 都會發生在雲端服務上，像 GCP、AWS 等等雲端服務都有自動機器讓整個 cluster 能擁有更多的資源可以使用。

K8s Auto Scaling 寫法

一樣我們先看個簡單的範例。

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: helloworld
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: helloworld
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 10

這邊可以發現 apiVersion 後面的值又不一樣了，這是因為 Auto Scaling 的部分在 K8s 中也有獨立的設定值就跟 Deployment 一樣，所以這邊要填上 autoscaling/v1。

再來可以看到 spec 的部分有一個設定值為 scaleTargetRef，這個代表在進行 Scaling 時的詳細依據，所以要填上針對哪個 ReplicaSet 或 Deployment 或 Replication Controller 等等用來管理 Pod 的物件資訊，這邊筆者就接續之前所介紹的 Deployment 來撰寫，所以就要填上 Deployment 的資訊，像是 apiVersion、kind、name。

之後可以看到 minReplicas 以及 maxReplicas，這兩個代表 Pod 數量的範圍，相信大家看到名稱也知道 minReplicas 代表 Pod 的最少數量而 maxReplicas 代表的是 Pod 的最大數量。

最後可以看到 targetCPUUtilizationPercentage 這個設定，在進行 Auto Scaling 的時候都是依據 CPU 的使用量進行擴展，而依據來源為 Resource Quotas 中的 Request 設定值。

假如今天 Resource Quotas 的 Request CPU 設定為 200m 而 Auto Scaler 設定的 targetCPUUtilizationPercentage 為 10，就代表當 Pod 的 CPU 使用率為 20m 的時候就要進行 Auto Scaling。

當然該 Pod 的 CPU 使用率還是可以使用到 Resource Quotas 中 Limits 設定的上限，只是在那之前 Auto Scaler 會先產生一個新的 Pod 出來。

Auto Scaling 建立

由於現在要讓 K8s 自行建立 Pod，因此我們必須要把 minikube 上用來監控流量的 addons 打開，這邊要打開的是 metrics-server。

接下來就可以透過 apply 這個參數把剛剛寫好的 HorizontalPodAutoscaler(HPA) 檔建立起來。

建立完後可以下 get 的參數查看 Auto Scaler，這邊可以發現 target 的部分為 <unknown>，這是因為 Auto Scaler 還在抓取目前 Deployment 流量的關係，假如我們沒有把 metrics-server 打開的話，這邊就會一直是 <unknown> 所以要請讀者特別注意一下。

等一小段時間之後，Auto Scaler 就會把流量抓取完畢了，這時候就可以看到 <unknown> 已經不見了。

接下來就可以稍微測試一下 HPA 是否有正常運行，這裡筆者就不斷的打網址輸出網頁內容看看是否真的會自動產生新的 Pod。

經過一段時間後，接下來在查看一次 HPA 的資訊，可以發現當流量開始超過我們設定的臨界值之後，HPA 就會開始產生新的 Pod 了。

可以看到 Replicas 的部分不斷的在增加直到我們設定的 MaxPods 數量後就不會再增加了。

最後可以把剛剛打網址的迴圈關掉，再等一段時間後就可以發現 HPA 也會自動地減少 Pod 直到我們設定的 MinPods 數量。

ReplicaSet v.s. HPA

相信大家應該會很好奇到底 Pod 的數量會跟著 ReplicaSet 走還是跟著 HPA 走，由於我們已經啟動 K8s 的自動擴展 Pod 的功能了，所以現在會變成 HPA 來控管 Pod ，即便今天將 Deployment 進行更新也不會依照我們設定好的 replica 的值而產生相對應數量的 Pod，所以筆者建議假如要設定 HPA，其 minReplicas 最好設定跟 Deployment 中的 replica 的值一樣。

小結

今天介紹了 K8s 是如何讓 Pod 自動擴展，相信大家應該更了解如何自動產生更多 Pod 了，但假如一直肆無忌憚的增加 Pod 要如何得知每個 Pod 是否都是健康的呢？

所以下一篇文章就要來介紹要如何在 Pod 中建立 Health Check，如果對於文章有任何問題都歡迎留言給我，那我們就下篇文章見嘍～